1. Field of the Invention
The present invention relates to the field of browser design and, more particularly, to a browser that uses a plug-in framework to extend a supported markup language.
2. Description of the Related Art
A browser is a program that audibly or visually renders documents based upon a markup language. A common type of browser is a Web browser that renders hypertext-markup language (HTML) based documents. HTML documents are often served by a Web server to clients over a network utilizing a packet based protocol. As used herein, the term HTML based document is used generally to refer to any document based on markup languages derived from HTML, such as an Extensible Markup Language (XML) document, a Voice extensible Markup Language (VoiceXML) document, a WML document, and the like.
Conventional Web browsers are able to utilize Web plug-ins, which are small pieces of code that extend a Web browser. Conventional plug-ins allow users of the Web browser to view media types other than HTML and images. There are hundreds of plug-ins that enable Web users to use a plethora of multimedia formats, including audio and video. Common examples of Web plug-ins include flash plug-ins for enabling MACROMEDIA FLASH objects, JAVA plug-ins, and portable document format (PDF) plug-ins for permitting browser users to view and manipulate PDF based documents within a browser.
Conventional browsers and browser plug-ins fail to extend the markup language supported by the markup browser. Instead, conventional markup plug-ins are based upon standard HTML documents and standard markup language constraints. Consequently, plug-in designers often construct complex scripts, JAVA applets, or use the <object> markup tag in an attempt to compensate for a lack of a desired markup language extension. Because every mainstream browser has browser specific idiosyncrasies, designers must conduct exhaustive script testing against different browsers. It is typical for a plug-in to first identify a browser that the plug-in is executing within and then to execute different code depending on the browser being used.
Another alternative that is used by developers to extend a markup language is to require users to use a proprietary browser, specifically designed to include a markup extension. Constructing a proprietary browser is a complex and costly task, especially when the desired feature or language extension is for a relatively minor, yet significant, feature. Additionally, reliance upon proprietary browsers greatly limits the marketability of a product. Consumers want to use a Web browser with which they are familiar that has been customized to their preferences and are reluctant to adopt a proprietary browser, especially when that browser is only used to access information from a single content source.
What is needed is a mechanism for extending a markup language so that new tags, language features, and the like can be specified and used without requiring browser source code to be modified. Such a mechanism would allow developers to more easily construct markup applications. For instance, designers could extend the markup language using the proposed mechanism instead of relying upon “work arounds” based upon language constrained scripts.
The proposed mechanism could also be used to enhance a user's browsing experience. For instance, using the mechanism to extend a browser's supported markup language would result in integrated extensions that more closely conform to user perceived “standards.”
To illustrate, users commonly are confused when viewing PDF documents within a browser because buttons and features specific to the “PDF” plug-in must be used instead of standard browser buttons and features. For example, the find, copy, cut, and paste features of the browser are not enabled for a PDF document contained within a browser that uses a standard PDF plug-in. Instead, plug-in specific buttons and functions must be used/selected by a user wanted to perform functions, such as find, copy, cut, and paste. Implementing plug-ins in a fashion that prevents users from using browser buttons/functions results in user confusion and frustration. No known solutions permit developers to extend a browser's supported markup language at runtime.